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Abstract 

On going development and testing of an adaptable vehicle health-monitoring architecture is presented. The 
architecture is being developed for a fleet of vehicles. It has three operational levels: one or more remote 
data acquisition units located throughout the vehicle; a command and control unit located within the 
vehicle: and, a terminal collection unit to collect analysis results from all vehicles. Each level is capable of 
performing autonomous analysis with a trained expert system. The expert system is parameterized, which 
makes it adaptable to be trained to both a user’s subject reasoning and existing quantitative analytic tools. 
Communication between all levels is done with wireless radio frequency interfaces. The remote data 
acquisition unit has an eight channel programmable digital interface that allows the user discretion tor 
choosing type of sensors; number of sensors, sensor sampling rate and sampling duration for each sensor. 
The architecture provides framework for a tributary analysis. All measurements at the lowest operational 
level are reduced to provide analysis results necessary to gauge changes from established baselines. These 
are then collected at the next level to identify any global trends or common features from the prior level. 
This process is repeated until the results are reduced at the highest operational level. In the framework, 
only analysis results are forwarded to the next level to reduce telemetry congestion. The system’s remote 
data acquisition hardware and non-analysis software have been flight tested on the NASA Langley B757’s 
main landing gear. The flight tests were performed to validate the following: the wireless radio frequency 
communication capabilities of the system, the hardware design, command and control; software operation: 
and, data acquisition, storage and retrieval. 


Introduction 

Existing aircraft are often kept in service beyond their original design lives. As they age, they become 
susceptible to system malfunctions or fatigue. Unlike future aircraft designs that will have health 
monitoring capabilities integrated into their designs, older aircraft have not been able to benefit from such 
technology. NASA Langley Research Center is developing and testing a health monitoring 
hardw'are/software architecture designed to be retrofitted into existing aircraft and thus provide them with 
state-of-the-art health monitoring capabilities. The objective of the health monitoring system is to reduce 
vehicle operating costs, improve safety and increase reliability. Frequent vehicle monitoring allows 
identification of the embryonic stages of damage or degradation. This knowledge can be used to correct 
the anomalies while still somewhat minor. In an “Aerospace America” commentary (January 2002), the 



former FAA Administrator and former Secretary of the Air Force, John McLucas, suggested the need for 
an aircraft health monitoring system. The system he described has all the attributes of the NASA health 
monitoring software and hardware architecture currently being developed and tested. 

The architecture is a hardware and software infrastructure for health monitoring that can be easily 
developed to a health monitoring system. The architecture presented herein is being developed for a fleet 
of vehicles. It has three operational levels: one or more remote data acquisition units (RDAU), a command 
a control unit (CCU), and a terminal collection unit (TCU). Programmable data acquisition circuitry and 
expert systems trained to performance baselines in each RDAU allow the architecture to be adaptable for 
many types of vehicles and structures. The programmable data acquisition circuitry allows type of sensor 
and number sensors used to be at the discretion of the user. The circuitry allows the sampling rate for each 
sensor to be programmed. Wireless radio frequency transceivers are used to communicate with all of the 
architecture components. 1 

The architecture is capable of performing tributary analyses. The measurements collected at the lowest 
level are analyzed at that level. Analysis results are forwarded to a higher level and then all results are 
analyzed to ascertain global trends or anomalies for the prior level. This is repeated until all analyses are 
combined at the highest level. The architecture has three analysis levels. Each analysis level has a trained 
expert system. The lowest level consists of one or more remote data acquisition units (RDAU) capable of 
collecting and analyzing data. Each RDAU has multiple data acquisition channels. The RDAU can 
perform analysis on measurements from each channel individually or from all channels fused together. The 
second level is a command and control unit (CCU). The CCU is capable of performing vehicle level 
analysis. Each RDAU analysis results are forwarded to the CCU that can perform similar analysis but for 
all RADUs (i.e., the vehicle big picture). Global anomalies to the vehicle can be detected. The fused 
analysis can also be used to locate anomalies by triangulation. Spatial trends can also be identified using 
the fused analysis results. After the end-of-flight, a vehicle's CCU analysis is then forwarded to a terminal 
collection unit at the airfield. The terminal collection unit functions as a repository of all vehicle analyses 
and performs analyses using results forwarded from all vehicles. Here all vehicles can be compared to 
ascertain if there are common anomalies (e.g., vendor supplied bad brake pads, improperly manufactured 
linkage, etc). 1 

Having expert systems at each analysis level can eliminate the need for transmitting and storing large 
volumes of collected measurements. An expert system develops analysis results that are transmitted to the 
higher system levels. The expert systems are developed such that they can be adapted to any system. The 
expert system’s key analytic tool is fuzzy logic for inference logic based upon subjective reasoning and 
quantitative analysis. Fuzzy logic is used to emulate predicate reasoning (i.e., if ‘'A” then “B”) for many 
combinations of inputs which are used to form a decision. Fuzzy logic can also emulate human qualitative 
reasoning with the capability of incorporating multiple qualitative objectives. “ When pattern recognition is 
required, a neural network can augment the expert system. A neural network is a computational structure 
that emulates rudimentary biological neural processing. 

The health monitoring architecture provides a means for retrofitting the current fleet of military and 
commercial aircraft, ships, and ground vehicles with state-of-the-art health monitoring technology. The 
architecture is self-contained and requires limited integration intrusion into existing systems. In essence, it 
has “bolt-on/bolt-off” simplicity. The architecture is easy to implement on any existing vehicle or 
structure. 

The system's remote data acquisition hardware and non-analysis software has been flight tested on the 
NASA Langley B757’s most severe location to mount a health monitoring device: the landing gear. 
Following the introduction will be an overview of the architecture hardware and software. Results from the 
airworthiness pre-flight tests (pressure, vibration, thermal and electromagnetic interference testing) will be 
presented next. Hazard analysis will follow. A brief overview’ of the NASA Langley Research Center 
(LaRC) Boeing 757-200 Airborne Research Integrated Experiments System (ARIES) is then given. Flight 
tests results arc presented next. The next phase of the architecture development has already commenced 
and is described next. The next phase of development, that has already commenced. It includes installing 
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autonomous capability for data reduction and analysis using the expert systems. Finally, in this next phase, 
the RDUA units will also be placed throughout the aircraft. 


Architecture Overview 

The architecture is developed as a framework for tributary analysis for a fleet of vehicles. The three sub- 
systems of the health monitoring architecture are the remote data acquisition unit, the command and control 
unit and the terminal collection unit. The details of each sub-system will be presented in this section. The 
architecture is described in Ref 1 . 

Remote Data Acquisition Unit (RDAU) 

Remote data acquisition units (RDAU) are multi-sensor interfaces with an on-board miniature computer, 
programmable digital interface, nonvolatile solid-state memory and a wireless transceiver for 
communication with the command and control unit. The RDAU electronics and housing are shown in Fig. 
1. The software embedded in the RDAU computer provides transceiver control, encoder/decoder control, 
data file management. The autonomous analysis capability is currently being added to the architecture. 
The computer controls all functions for communication, data acquisition and storage. Sensor data is 
acquired via a flexible sampling scheme through a programmable digital interface. Currently a disk 
operating system (DOS) is being used which is to be replaced with a Linux operating system. A remote 
data acquisition unit can accommodate eight sensor measurements. Five A A Lithium batteries arc used to 
supply power to each RDAU. External power sources can also be used. The housing and the mounting of 
internal electronics are designed to withstand impact during aircraft landing while mounted on the main 
landing gear. It is also designed to operate in non-environmentally controlled locations of the plane. The 
device can operate at -50°C to 55 °C and pressure equivalent to 50,000 ft altitude. 

Any combination or type of sensors can easily be installed into the RDAUs. These sensors can be within 
the RDAU housing or external to the RDAU (e.g., connected with wires or flex circuits). Data acquisition 
circuitry is implemented in a single complex programmable logic device (CPLD). A complex 
programmable logic device can be reconfigured in-circuit. A device performing a similar function is a field 
programmable gate array. The circuitry controls all analog-to-digital conversion. A first in/first out sample 
buffer and the buffer status is regulated by the circuitry. Time division multiplexed (TDM) sampling is 
used to provide multiple sampling rates for the individual channels within a prescribed sampling period. 
When sensors are measuring physical properties with different rates of change, the multiple sampling rates 
eliminates excessive sampling of a property that changes at a slower rate. 

A transceiver operating at 433MHz was used for communication with the command and control unit. The 
transceiver used lmW of power. The transceiver used amplitude shift keying modulation (somewhat 
similar to amplitude modulation). The frequency does not electro-magnetically interfere with aircraft 
communication and navigation systems. A micro-controller regulates the transceiver power management 
logic. The transceiver power management algorithm regulates the RDAU transceiver to power-off for 2 s, 
then power-on for 2 ms to acquire any commands broadcast from the command and control unit. It then 
returns to power-off for 2 s if no commands are broadcast. The algorithm continuously cycles the 
transceiver power in the aforementioned fashion. If there are broadcast commands, the transceiver remains 
on until the commands are completed. Each RDAU has an addressable encoder/decodcr. Commands can 
be received directly through the encoder/decoder. RDAU status and data are received through serialized 
packet format. 

Once a suite of sensors arc chosen for each RDAU and located on the vehicle, a baseline of acceptable 
vehicle performance is established from measurements acquired when the vehicle is performing correctly. 
Each RDAU uses an embedded expert system trained to its respective baseline. The expert system will be 
discussed in a later section. Expert systems are currently being added to the RDAU processor to 
incorporate both subjective human reasoning and other analysis algorithms in all operational levels of 
autonomous analysis. Once trained, the expert system uses anomalies to the baseline patterns to identify 
possible changes to vehicle structure or subsystems. The expert systems provide a means to autonomously 
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gage how significant measured changes to established baselines are. Transceivers are used to communicate 
between all system levels. Analysis results are transmitted to higher system levels in lieu of all collected 
data to eliminate telemetry congestion. 


Channel 

Measurement 

1 

Acceleration in 
velocity direction 

2 

Acceleration along 
pitch axes 

3 

Acceleration in 
vertical direction 

4 

Sound 

5 

RDAU Temp 

6 n 

Battery Voltage 

7 

Spare 

8 



Table 1 Remote data acquisition channel allocation 

Each RDAU can sense numerous physical attributes (e.g., sound, heat, or mechanical disturbance) within 
vicinity of a RDAU. Table 1 lists measurements of each channel during the flight tests. In nominal 
operation, each physical attribute sensed by a sensor interfaced to a RDAU has a performance envelope or 
established pattern that are indicative of the system (vehicle or plant) being and/or functioning within 
acceptable limits. Examples of these arc measured landing gear loads during impact not being exceeded; 
brake noise frequency spectral content within established range, no major changes to structural frequencies 
that can be sense by a RDAU, or no anomalies in audio or vibration signatures. Basically, each RDAU has 
a collection of measurement signatures (i.e., profiles) established from measurement during correct and 
non-damaged operations of the system. Measured profiles that show alterations to the signatures infer the 
system has changed. 
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Command and Control Unit (CCLJ) 


The command and control unit is a computer-based subsystem that provides the communications, analysis 
repository, and user interface functions for RDAU control, data archiving, and analysis. The command and 
control unit is shown in Fig 2a. Fig 2b shows the transceiver for the CCU. The CCU can also serve as a 
power management tool by regulating when individual or combinations of RDAUs are powered on. A 
simple radio frequency (RF) wireless network of RDAUs can be controlled from a single CCU. 
Communication, for RDAU control, is provided via a custom wireless RF transceiver interface. The CCU 
can be manually controlled and reconfigured via standard computer interfaces (e.g., standard serial cable to 
a portable PC such as a laptop, personal digital assistance; or, keypad). If the CCU must be embedded 
further into the vehicle/plant, control and configuration could be carried out remotely via a RF 
communication. A user interface is provided to allow the user to control functions for a selected RDAU. 
Data and/or analyses, downloaded from the associated acquisition units, arc archived for the next level of 
analysis. 

The CCU regulates the health monitoring architecture. It has a wireless transceiver to communicate with 
all RDAUs via two-way RF. The CCU controls all RDAUs with the following commands: power on-off, 
acquire, trigger, stop, reset, status and download. It has the ability, using expert systems, to reduce and 
analyze all data collected. The CCU can be controlled and reconfigured manually by use of any portable 
PC such as a laptop, personal digital assistant via a standard serial port. A keypad with LCD display is also 
part of the CCU. Currently a disk operating system (DOS) is being used which is to be replaced with a 
Linux operating system. 


Terminal Collection Unit (TCU) 

The terminal collection unit (TCU) provides the means to autonomously retrieve vehicle analysis results 
from all vehicle CCUs. The TCU performs analysis on all results collected from all vehicles to identify any 
fleet-wide anomalies (e.g., all aircraft have the same faulty bearing at a similar location). The TCU will be 
used to develop the final summary of the vehicle health monitoring results that gets routed to the 
appropriate users (e.g., maintenance workers, airlines operations, etc.). The TCU is currently under 
development. A portable system that contains the non-analysis capabilities of the TCU has been 
successfully demonstrated to download data after flights. The TCU is embodied as a Linux-based 
processor with RF communication, internet connectivity, expert systems and installed software similar to 
that to be installed on the CCU. The TCU will constantly transmit a “power on” command while awaiting 
the arrival of vehicles to within range of its transceiver. This command is repeated until there is a vehicle 
with CCU in vicinity. When a vehicle is in vicinity, its CCU will be powered on and then all collected 
analysis will be transmitted. All newly collected results arc then compared to those of other vehicles that 
have been collected. Any fleet wide anomalies are then automatically reported to appropriate users via 
shell commands which query the appropriate directories for new analysis reports and then to forward 
reports via emails or file transfer protocols. 
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Airworthiness Pre-Flight Testing 


Pre-flight tests were performed to validate the airworthiness of the remote data acquisition unit. The tests 
were to verify the operation of all electrical components, software and radio frequency communication. 
The tests performed were thermal cycling, pressure, vibration and electromagnetic interference. The 
integrity of the mechanical design which included housing and mounting of electrical components was 
partially verified during vibration testing. The complete validation of the design was the objective of the 
flight tests. 


Thermal Testing 

The remote data acquisition unit was operated at various temperatures to verify its ability to function at 
those temperatures. The RDAU was placed in a Tenney Jr. Temperature Chamber for eight continuous 
hours. The chamber is shown in Fig 3. The temperature in the chamber was varied according to the 
temperature profile shown in Fig. 4. Fig 4 shows the profile used for the pre-flight qualification test and 
results of the qualifying test. Results of thermal testing prior to the qualifying test are also shown in Fig 4. 
During qualification, there were four periods at which the temperature was held constant. The temperature 
rate of change between the holding periods was approximately 2.5°C per minute. Temperature variation 
for flight qualification was from 20°C to -40°C to 55°C to 20°C. During preliminary testing the 
temperature varied from 20°C to -50°C to 20°C. The temperature was maintained at -50°C for 5 _ hours. 

Operation verification points are annotated on Fig 4. At each measurement time, the RDAU was 
commanded by the CCU to POWER ON. The POWER ON command instructed the computer that 
controlled data acquisition to be turned on. The CCU then transmitted an ACQUIRE command which 
instructed the RDAU to acquire measurements for all eight channels. Following the ACQUIRE command, 
the CCU transmitted a DOWNLOAD command which instructed the RDAU to transmit data packets to the 
CCU while the CCU received and stored the packets. A POWER OFF command was then sent to the 
RDAU to place the RDAU in a sleep mode. In the sleep, mode the computer which is used to control data 
acquisition and data storage was powered off. The micro-controller that controls the transceivers initiates 
the power management algorithm. The data received and stored by the CCU was then examined. The data 
was manually examined to verify that the correct pre-selected count (for reference channel) and the correct 
number of bytes for other the channels was received. The time and temperature of the oven was recorded 
at different intervals. The RDAU functioned correctly at all measurement points for all tests. 


Altitude Testing 

To emulate pressure conditions at 50, 000 ft, the RDAU was placed in a Process Equipment Co. vacuum 
chamber with the chamber pressure decreased to and stabilized at 87.0 mm Hg (pressure at 50,000 ft for 
standard day). The chamber is shown in Fig 5. The test initiated with the chamber temperature at ambient 
temperature. The RDAU was positioned in the chamber so that it could be viewed through the front 
window of the chamber. Since the RDAU was battery operated with a radio frequency transceiver, no 
wiring connections were necessary. A radio frequency spectrum analyzer was used to verify that 
communications signals were either sent by the command and control unit or by the RDAU. During 
testing, the CCU was external to the vacuum chamber. The RDAU was tested prior to the altitude test to 
assure that it was working properly. Transceiver communication between the CCU and RDAU was 
verified before start of test with the pressure chamber door closed. 

The chamber pressure was decreased to 87.0 mm Hg and maintained at that pressure for two hours. The 
RDAU performance was monitored during the two hours by acquiring measurements from all channels 
every 30 minutes. No malfunctions were observed for either the CCU or the RDAU during the altitude 
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test. The operation of the RDAU was again verified after the vacuum chamber pressure was increased to 
ambient and the chamber was opened. 


Vibration Testing 

To verify that the remote data acquisition unit could operate during vibration that was representative of 
what commercial transports could experience, the RDAU was subjected to a vibration test. A T1000 
Unholtz-Dickie vibration table, shown in Fig. 6a, was used to provide the desired acceleration. The RDAU 
was subjected to the two sinusoidal vibration spectrums shown in Figs. 7 and 8 for each orthogonal axes 
shown in Fig 6b. Both sine-sweep tests were conducted in each axis before changing to next axis 
orientation. During the standard sinusoidal test (Fig 7), the frequency of acceleration was increased from 
10 Hz (at 0.51 lg) to 2000 Hz at a rate of 1 octave/min. The final acceleration amplitude was 20g. At 2000 
Hz, the sweeping frequency was decreased at 1 octave/min until the vibration table acceleration frequency 
reached 10 Hz. Similarly, during the high level short duration sinusoidal test (Fig. 8), the acceleration 
frequency was increased from 10 Hz to 250 Hz at a rate of 0.166 Hz/s. The sweep was also reverse after 
reaching 250 Hz. Two diagonally mounted accelerometers were mounted on the table for reference 
measurements. During testing, a spectrum analyzer was used to verify radio frequency transmissions from 
the RDAU. The command and control unit was placed in the vibration table control room. 

Before testing each axis, the RDAU was turned POWERED ON to verify operation. Shortly after the 
sinusoidal sweep started, the RDAU was commanded to record 10 seconds of data. Audio and acceleration 
measurements acquired during the Y-axis vibration tests are shown in Fig. 9 for 0.05 s. The measurements 
were taken when the table was vibration at approximately 240 Hz. After each sinusoidal sweep has ended, 
the RDAU was commanded to download the data to the CCU. The CCU file directory was examined to 
verify the download. After the download was verified, the RDAU was commanded to the sleep mode. No 
malfunctions were observed for either the CCU or the RDAU during all vibration sweeps. 


Electromagnetic Interference Testing 

Research experiments that fly on the NASA Langley Research Center (LaRC) Boeing 757-200 Airborne 
Research Integrated Experiments System (ARIES) must be tested to determine if they cause 
electromagnetic interference to communication receivers and/or navigation receivers on-board the 
aircraft. 3 ' 4 Aircraft-level testing was performed when there were major configuration changes on the 757 
ARIES. Experimental equipment was normally required to be cleared for all phases of flight, including 
takeoff and landing. Any interference to the communication and navigation equipment is a potential safety 
risk. C. H. Rollins provides (Ref. 3) a very detailed description of the testing required for flight. Features 
of testing relevant to the health monitoring system are summarized in this section. 


Table 2. Receiver Antenna Port Measurements 


Receiver Measured 

Frequency Range (MHz) 

Marker Beacon 

74.8 - 75.2 

VOR 

108-118 

ILS Localizer 

108.1 - 1 12 

ILS Glideslope 

328-335 

UHF 

225 - 400 

VHF 

118- 138 

DME 

960- 1220 


The aircraft-level testing determined the interference from the research equipment to the communication 
and/or navigation receivers. Interference to other systems was determined during Instrumentation Check 
Flights (ICFs). The aircraft-level testing provided the exact environment and RF coupling paths thereby 
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producing more accurate results than could be achieved if the individual instruments were examined in 
electromagnetic interference laboratory. Because the radiated emissions profile for the research system 
was not known, the entire operational band was swept for each receiver. 

Aircraft-level testing was performed after all research pallets passed flight quality assurance inspections. 
All research pallets were in flight configuration and were operating in a normal flight mode for this testing. 
The interference levels were measured at the antenna ports for each of the communication and navigation 
receivers and then the receivers were tuned to any suspect frequencies to determine if the level was 
sufficient to cause interference. The electromagnetic interference test measured the level of noise at the 
input to the receivers listed in Table 2. Operational frequencies for the receivers are also listed in Table 2. 

During measurements, the applicable aircraft receiver’s antenna was used as the measurement antenna. 
The signal received from the antenna is used as the input to a spectrum analyzer. Fig 10 shows the analyzer 
connected to an antenna via a coaxial cable. The measurement scan of the receiver band was first 
performed with all research equipment powered off. The applicable receiver frequency band was scanned 
using the spectrum analyzer. A minimum of three sweeps was made at each frequency band to determine 
the baseline response and to ascertain any significant noise present. The purpose of the baseline scan was 
to identify any noise that was not due to the research system. Next, the measurement scan was performed 
with all the research equipment powered on. Any noise signals measured are compared to those recorded 
in the baseline scan. If the signal was not previously identified, the frequency and level are recorded and 
the signal plotted. Next, the research pallets were powered down one at a time while displaying each 
identified signal. The source of the potential interference signal was identified when the signals were not 
present when the equipment was powered off. Once the research pallet was identified, individual 
equipment on the pallet was powered on and off to determine the source of the interference within the 
research equipment. This procedure was repeated for each receiver listed in Table 2. 

After the potential interference was identified, a receiver check was performed. The receiver check 
determined which potential interference signals were of sufficient strength to cause interference to the 
communication receivers. These frequencies of interference and the source of interference were reported to 
the pilots so that they were aware of any unusable communication frequencies. It is difficult to detennine 
interference to the navigation receivers during the receiver checks. Therefore, all frequencies of potential 
interference to the navigation receivers were reported to the pilots and the sources of the interference were 
noted so that the pilots were aware at what frequencies the receivers may experience interference. 

By performing a functional check of critical and essential systems, the pilots determine any interference to 
other systems during the lCFs. The correct operation of the navigation receivers at the identified potential 
interference frequencies was also verified during the lCFs. A functional check of as many instrument 
operational modes as possible for the applicable phases of flight was performed. 

The major source of electromagnetic emission from the health monitoring system was from the use of the 
radio frequency transceivers. The transceivers operated at 433 MHz which was above the UHF band (225 
- 400 MHz) and significantly below the DME band (960 - 1220 MHz). The entire emission of the health 
monitoring system had no influence on the UHF antenna. No other systems had operational frequency 
bands for which the health monitoring system could possibly interfere. The transmission frequency and 
harmonics did not fall within any of the radio frequencies communication and navigation bands checked. 
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Potential hazards were identified and analyzed to assure safety during the test flights. The initial flight tests were performed with the remote data acquisition unit 
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Table 3 Potential hazards associated with remote data acquisition unit being mounted on main landing gear 





Table 3(Continued) Potential hazards associated with remote data acquisition unit being mounted on main landing gear 







The Airborne Research Integrated Experiments System (ARIES) 

The Airborne Research Integrated Experiments System is a Boeing 757-200 that has had its cockpit and 
fuselage reconfigured to serve as a platform for experimental aerospace and atmospheric science systems. 
The ARIES is shown in Fig. 11. The aircraft was manufactured inl983 for Eastern Airlines. The ARIES 
can easily support multiple experiments concurrently. The aircraft characteristics are given in Table 3. 
The baseline research configuration of the ARIES includes twelve instrumented test pallets/research 
stations. Additional pallets and research equipment can also be installed [1]. The pallets are primarily 
located in the passenger cabin. Each pallet has dual video monitors and an UTC synchronized time display. 
Video cameras are located in the landing gear well pointing toward the gear; on the aircraft tail pointing 
forward; in the rear cockpit with view of cockpit; and, forward cockpit providing a nose view. 

Other equipment is located throughout the aircraft, such as research displays mounted in the forward flight 
deck and a telemetry pallet located in the aft life raft overhead storage compartment. There are external 
video cameras and various special-purpose antennas and sensors in other locations. 


Aircraft type 

Boeing 757-200 

Engines 

Two Rolls-Royce RB21 1 

Maximum thrust 

43,100 Lb 

Wing Span 

1 24ft 10 in 

Height 

44ft 6in 

Length 

155 ft 3 in 

Maximum take-off weight 

230,000 lb 

Maximum operating altitude 

42,000 ft 

Maximum speed 

350kts (Mach 0.86 

Acceleration force limits 

2.5g to -l.Og 


Table 3 NASA Langley Research Center ARIES dimension and performance characteristics 








Right Test Results 


There were 13 flight tests of the remote data acquisition unit and the command and control unit on the 
NASA Langley ARIES. Four test flights were completed in August 2001. Nine additional tests were 
performed from March May 2002. During all tests, a single RDAU was mounted on the left main landing 
gear as shown in Fig 12. The command and control unit was mounted in a research pallet of the NASA 
Langley Research Center (LaRC) Boeing 757-200 Airborne Research Integrated Experiments System 
(ARIES). The flight test objectives were to validate the following: the wireless communication capabilities 
of the system, the hardware design, command and control; software operation; and, data acquisition, 
storage and retrieval. A very rigorous test of the mechanical design was achieved by mounting the device 
on the landing gear. The sensors listed in Table 1 were used to measure and record acoustic and dynamic 
response in proximity to main landing gear. During the initial flight tests, none of the autonomous features 
had been installed. The system was functioning as a remotely controlled data acquisition device. 

The four flight tests of 2001 validated the mechanical design and software design. Examination of data 
files verified that all commands transmitted from the CCU were received by the RDAU. However, when 
the RDAU was commanded to return a status code or data, the communication was not consistent. Signals 
from the CCU to the RDAU were sent by an encoder connected to the parallel port. This encoder takes 
four bits from the parallel port and encodes them into a special signal that can be transmitted by the 
transceiver. This encoded signal was repeated several times during the transmission to ensure it gets 
through. The RDAU has a decoder that is matched to the CCU transceiver encoder. However, data and 
status signals from the RDAU were sent back as a standard RS-232 signal from the main RDAU computer. 
This signal was in the form of a packet that was recognized by the software in the CCU. A status reply was 
sent as one packet. The low powder transceiver required extremely good ambient radio frequency 
conditions for the RDAU signals to be received by the CCU. Incomplete packets were not recognized by 
the computer. The best conditions for reliable RDAU transmission and CCU reception occurred when the 
gear was down and the runway (or taxiway) area beneath the wheels were not covered with rubber tire 
marks. Condition such as when the gear was retracted in the wheel well resulted in numerous loss 
receptions. 

Thee encoder/decoder pairs were designed to be used in remote control applications. To improve reception 
of signals coming from the RDAU, an encoder was added to the RDAU computer parallel port and a 
decoder was added to the CCU transceiver interface box. This encoded signal contained information on 
file storage and measurement acquisition mode. The redesigned health monitoring architecture now has 
two methods to query the RDAU: the original RS 232 signal and the additional encoder/decodcr pair. The 
modified architecture now has one encoder/decoder pair for sending CCU commands and another 
encoder/decoder pair for sending RDAU status and data. 

The nine flights in 2002 were used to evaluate the modifications that were made after the first series of 
flights. All modifications greatly enhanced the performance of the system. The 4-bit encoder resulted in 
better communication connectivity between the RDAU and CCU. Flight test engineers were able to 
determine the recording status of the RDAU more reliably. For example, the flight test engineers could 
easily determine whether the RDAU was armed, triggered, or whether data had been collected. Other 
modifications between flight series were to mount sensors on RDAU casing and to have multiple files for 
storing measurements. 

Measurements acquired during flights included take-offs; landings; vibration while gear was fully retracted; 
taxiing; and, touch and go landings. A measurement of a touch and go landing is shown in Fig 13. The 
measurement is taken from the accelerometer parallel to the velocity of the aircraft. The landing event was 
approximately 15 s in duration. The objective of the measurements was not to analyze the measured data 
but to validate the means to acquire the measurement. Fig 13 demonstrates that the remotely controlled 
data acquisition capability works. 
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Future Work 


Key attributes of the system have been demonstrated during flight tests on the NASA ARIES. The next 
phase of development is to apply expert systems that have been also developed at NASA Langley Research 
Center. The expert systems use parameterized fuzzy logic algorithms that allow the input-output mapping 
to be tuned. The expert systems will be installed to provide a means for performing autonomous analysis. 
A brief description of the expert systems is given in the next section. 

Other future work is to use Linux operating systems at all operational levels of the architecture. The final 
goal is to install RDAUs throughout the aircraft and perform flight tests to demonstrate all operational 
levels including the terminal collection unit currently under development. All amplitude shift keying 
modulation transceivers will be replaced with frequency modulated transceiver with variable power control 
(1-10 mW). A frequency modulation transceiver is less susceptible to noise. Secured wireless cell phone 
chips are another possible communication option. The terminal collection unit is being developed as 
discussed in an earlier section. 

Future development goals of the remote data acquisition unit include lower power consumption. The 
hardware casing is to have a smaller volume and area footprint. Sensors will be external to the housing and 
placed on flex circuits. The unit will have a wireless laptop/desktop PC control, communication and 
collection interface. The unit will have the ability to use vehicle power. New versions of the digital 
interface will have the processing capability of the on-board computer currently being used. The dual 
functionality of the digital interface will make it possible to eliminate the on-board computer. The digital 
interface requires less power consumption thereby requiring fewer batteries. The volume and area footprint 
of the RDAU will greatly be reduced because the RDAU computer is removed (less area) from the circuit 
board and fewer batteries are required (less volume). Many of the operational features of the RDAU will 
be transitioned into a system-on-chip based design. System-On-Chip (SoC) incorporates the processor and 
most of the peripherals and interfaces onto one chip. Benefits of SoC include reduced physical properties 
(mass, dimensions, power), reduced PCB layout, flexible external interface capability, and ease of 
software/hardware integration, and reduced development through softwarc/hardware co-design methods 
allowed by such a design. This type of design can be implemented using available FPGA, CPLD. and 
highly-integrated micro-controller offerings from various companies. 

The future design changes to the command and control unit are to make the unit portable and self- 
contained. The unit is to be placed within a small volume ruggedized chassis which should make the unit 
easy to carry. The transceiver circuitry shall be placed within the chassis. The will also be a keypad 
interface and liquid crystal display. The CCU will use external power source but have Lithium batteries as 
a power back-up. SoC design will also be incorporated into future CCU designs to make the architecture 
attractive to small privately owned aircraft and other smaller vehicle. 


Expert System Overview 

Expert systems will be implemented in all operational levels of the health monitoring architecture to 
facilitate autonomous analysis. They will also provide decision logic for the CCU (c.g., for regulating 
RDAUs). The expert systems will be developed from tuned fuzzy mapping algorithms. The expert 
systems will allow' subjective reasoning to be applied to all results (or measurements) in addition to 
quantitative analysis. When pattern recognition is required for the expert systems, neural networks can be 
used. Fuzzy logic mapping algorithms and neural networks are used because they are computationally 
efficient. Ref 2 provides a detailed description of the development of the fuzzy expert system that is used 
in this health-monitoring architecture. Fuzzy logic is used to emulate predicate reasoning (i.e., it “A then 
“B”) for many combinations of inputs which are used to form a decision. Fuzzy logic can also emulate 
human qualitative reasoning with the capability of incorporating multiple qualitative objectives. 
Conceptually, a fuzzy expert system is similar to that of a decision-logic architecture using a collection of 
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binary “if-then” rules. The advantage of using fuzzy logic expert systems is that they can interpolate or 
extrapolate with fewer rules than the traditional binary’ expert systems. Fuzzy expert systems are robust. 
They have been shown to produce very good results in cases where the mathematical description of the 
system being controlled or analyzed may not be readily available; the description may be of questionable 
fidelity; or, the inputs are imprecise. 

A fuzzy expert system development algorithm has been developed at NASA Langley Research Center that 
will allow users to develop a fuzzy expert system without having to be knowledgeable in fuzzy logic. The 
development algorithm is optimization based. The development algorithm only requires that a user defines 
his/hers subjective reasoning into a set of decision rules of the form, “If A and If B ... then C.” The user 
also supplies examples of metrics for those rules. The rules form a rule matrix. Nested in the expert 
system development algorithm is a fuzzy mapping algorithm that dynamically sizes its working matrices to 
accommodate the user-supplied rules. The mapping algorithm is capable of determining permutations of 
all rules executed based upon current inputs. The development algorithm uses the rule matrix to develop an 
optimization design vector based upon the number of fuzzy membership sets in the rules. The user- 
supplied metrics are used to tune the expert system via an optimization strategy. The optimization design 
objective is to minimize the error between the user supplied output metrics and the outputs the mapping 
algorithm creates for the same set of inputs. The design vector is varied using methods such as gradient or 
genetic algorithms. The fuzzy expert system is tuned when a design vector is developed such that w'hen 
implemented in the fuzzy mapping algorithm, the mapping algorithm's output approximates those of the 
user for a given set of inputs. Before the development algorithm, making a fuzzy expert system required 
the user to formulate membership functions for various fuzzy sets; develop rules that map input conditions 
to decisions using fuzzy sets; and, select fuzzification and defuzzification techniques for a small number of 
options. 

The remote data acquisition unit expert system will be trained using measurements collected when the 
vehicle is operating according to design are used to establish a baseline. The user defines the significance 
(e.g., how bad does the measurement indicate the vehicle is?) of new measurements that are acquired which 
are not within established envelopes of the baselines. This gives the architecture the ability to 
autonomously analyze measurements to ascertain the health of the vehicle. The expert systems for the 
command and control unit and the terminal collection unit will be developed in a similar fashion. 
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Conclusions 


On-going development and testing of an adaptable vehicle health-monitoring architecture has been 
presented. The objective of the health monitoring architecture is to reduce vehicle operating costs, improve 
safety and increase reliability. The architecture is being developed such that it can be retrofitted into a fleet 
of vehicles. There are three operational levels to the architecture: one or more remote data acquisition units 
located throughout the vehicle; a command and control unit located within the vehicle; and. a terminal 
collection unit to collect analysis results from all vehicles. 

Fuzzy expert systems will be implemented in all operational levels. The expert systems are developed such 
that they can be trained for any vehicle or structure to perform autonomous analysis. The expert systems 
are parameterized to allow them to be adapted to a given suite of sensors. Expert systems provide a means 
to include an user’s subjective reasoning and quantitative methods into autonomous analyses. Once a suite 
of sensors are chosen for each RDAU and located on the vehicle, a baseline of acceptable vehicle 
performance is established from measurements acquired when the vehicle is performing correctly. The 
RDAU embedded expert system can then be trained to its respective baseline. 

The architecture provides an infrastructure for performing tributary analyses. The measurements collected 
at the lowest level are analyzed at that level. Analysis results are forwarded to next operational level and 
then all results are analyzed to ascertain global trends or anomalies for the prior level. This is repeated 
until all analyses are combined at the highest level. The advantage of the having expert systems at each 
analysis level is that it can eliminate the need for transmitting and storing large volumes of collected 
measurements. Forw arding only analysis results to the next operational level reduces telemetry congestion. 

The remote data acquisition unit has an eight channel programmable digital interface which allows the user 
discretion for choosing type of sensors; number of sensors, sensor sampling rate and sampling duration for 
each sensor. The parameterized trainable fuzzy expert system and the programmable digital interface make 
health monitoring hardware and software infrastructure adaptable to many vehicles and structures. 

All communication within the architecture is done with wireless transceivers operated at 433 MHz and 1 
mW. Electromagnetic interference tests have demonstrated that the radio frequency emissions from the 
transceivers have no influence on any of the aircraft communication and navigation antennae. The remote 
data acquisition unit has been thermally tested for temperatures ranging from -50°C to 55°C. Pressure 
testing verified that the RDAU could be used in non-environmentally controlled spaces on an aircraft at 
50,000 ft altitude. Vibration tests verified that the remote data acquisition unit could operate during 
vibration representative of that which commercial aircraft experience. During vibration testing, the final 
acceleration amplitude was 20g at 2000 Hz. 

Potential hazards were identified and analyzed to assure safety during the test flights. Extensive 
airworthiness and safety reviews of the remote data acquisition unit design and the preflight testing was 
used to alleviate the potential hazards identified. Installment of all health monitoring subsystems was given 
thorough flight quality assurance inspections. 

There were 13 flight tests of the remote data acquisition unit and the command and control unit on the 
NASA Langley Airborne Research Integrated Experiments System (ARIES). The flight tests were 
performed to validate the following: the wireless radio frequency communication capabilities of the system, 
the hardware design, command and control; software operation; and, data acquisition, storage and retrieval. 
A very rigorous test of the mechanical design was achieved by mounting the device on the left main 
landing gear. During the initial flight tests, none of the autonomous features had been installed. The 
system functioned as a remotely controlled data acquisition device. 

Four test flights w ere completed in August 2001. The four flight tests of 2001 validated the mechanical 
design and software design. The tests indicated that radio frequency communications needed to be 
modified to be more reliable. Another 4-bit encoder/decodcr pair was added to the system. Multiple data 
storage files were added. The nine flights in March - May 2002 were used to evaluate the modifications 
that were made after the first series of flights. All modifications greatly enhanced the performance of the 
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system. The final series of flight tests demonstrated that the remotely controlled data acquisition capability 
worked correctly. 
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a. Remote data acquisition unit electronics 


b. Remote data acquisition unit housing 


Fig 1. Remote data acquistion unit (RDUA) 



a. Command and control unit mounted on NASA b. Command and control unit transceiver mounted 
Langley Boeing 757 experiment pallet at rear of experiment pallet 


Fig. 2 Command and control unit 



a. Temperature chamber b. RDAU inside chamber before testing 

Fig. 3 Tenney Jr. Temperature Chamber used for testing RDAU operation during thermal cycling 
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Fig 4 Temperature profile used for thermal cycling remote data acquisition unit. Measurement occurred 
during the times annotated with the asterisk. 
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a. Process Equipment Co. Vacuum Chamber 


b. RDAU inside chamber before testing 


Fig. 5 Process Equipment Co. Vacuum Chamber used for testing RDAU operation at pressure emulating 
50,000 ft 



a. TIOOOUnholtz-Dickic vibration table. b. Axis orientation of RDAU during vibration 

testing. 


Fig 6. Vibration table and RDAU during vibration testing. 
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Fig 7 Standard acceleration profile used during vibration testing for each axis. 
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Fig 8 Acceleration profile during vibration testing used for each axis. 
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Fig 9 Vibration response measured using RDAU during vibration test compare to accelerometers mounted 
on vibration table. 
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Fig 10 Frequency analyzer with signal input from an electromagnetic interference receiver. 
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Fig 1 1 Langley Research Center (LaRC) Boeing 757-200 aircraft: Airborne Research Integrated 
Experiments System (ARIES). 
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a. Left main landing gear with RDAU 


b. RDAU mounted on tow fitting of landing gear 


Fig. 12 Remote Data Acquistion Unit (RDUA) mounted on NASA Langley Boeing 757 main landing gear. 


260 

Forward 

Acceleration 240 
(counts) 

220 
200 
180 
160 
140 
120 

Fig. 13 Forward acceleration measured by RDAU during touch and go landing at Langley Air Force Base 
(April 24, 2002) 
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